Inline. Thanks!
> Cameron Byrne <mailto:cb.list6@gmail.com>
> 25 August 2012 22:40
> Hi Ray,
>
> On Sat, Aug 25, 2012 at 12:27 PM, Ray Hunter<v6ops@globis.net>  wrote
>> The single /64 deployment model conflicts with previous approved IETF BCP. I
>> was also vocal in the discussion on 6204bis.
>>
>> Specifically: According to BCP 157 RFC6177 "A key principle for address
>> management is that end sites always be able to obtain a reasonable amount of
>> address space for their actual and planned usage, and over time ranges
>> specified in years rather than just months."
>>
>
> Without ND proxy, the amount of address you have is exactly zero for a
> tethered device in all of today's 3GPP networks.  So the question is
> do we do allow tethering on IPv6 today or do we say "no, IPv6 is
> future exercise for someone else".  Failing to engineer for it now
> makes yet another chicken-and-egg issue.  No customers, no demand, no
> spec, no gear, no code, ...
Understand that. No problem with a phone using xlat for it's own 
internal mono-stack apps. Or in a stand alone LAN where the phone is the 
only router.

I'm just trying to understand interoperability when there's more than 
one device present: either in parallel or cascaded.

When asked what happens when CLAT's are cascaded I got an answer back 
that this was out of scope of the draft. If I read ND Proxy I think that 
this case is illegal and that ND proxy processing will be disabled [ 2nd 
CLAT will receive an RA message with the P bit set on its upstream 
interface]

But there's no such explicit protection or detection of cascaded IANA 
assigned EUI-64 ID addresses in XLAT, which would definitely cause an 
IPv6 address conflict with the upstream CLAT. It strikes me as odd that 
ND Proxy goes to the trouble of detecting and shutting down the 2nd ND 
proxy if there's cascading, but XLAT BCP doesn't.

Why not explicitly shut down the affected functions of the downstream 
CLAT if it detects a duplicate IANA assigned EUI-64 address on it's 
upstream interface? Wouldn't that protect existing service from the 
upstream CLAT?
> On my 3GPP Release 7 network, you may tether today with NDproxy and
> have access to the WAN /64 on your LAN.
>
> As soon as kit arrives that can do DHCP-PD, that will be the preferred
> mechanism.
>
> I believe that is clearly documented here:
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2

> IF DHCP-PD available, then use DHCP-PD to grab as much address space as needed
>
> Else if NDproxy available, do that
>
> Else if EUI-64 reserved address available, do that.
>

I have read 8.3.2 and it does not seem to be worded exactly as you suggest.

Currently it's worded in the negative "if cannot X then can Y", and in 
some places it doesn't even use reserved keywords in capitals.

That to me does not express a preference for good behaviour of an "if X 
then SHOULD Y else MAY Z ....." clause.

I'd prefer this section to be worded in the positive (this is Best 
Current Practice) to give the preferred translation order (exactly as 
you state, using if then else...  ), and thus avoid perpetuating bad 
practice of single /64 working, and ensure interoperability if devices 
are swapped out.


Here's my (non expert) version of the text:



In the case that DHCPv6-PD [RFC3633] is available, the CLAT SHOULD use a 
dedicated IPv6 prefix for stateless translation [RFC6145]. ND Proxy 
andIANA assigned EUI-64 ID based addresses SHOULD NOT be used.

If the CLAT does not have a dedicated IPv6 prefix available for 
translation, the CLAT SHOULD attempt to perform NAT44 and stateless 
translation [RFC6145] as detailed in the following paragraph.

IPv4 packets from the LAN SHOULD be translated using NAT44 to the 
private IPv4 host address of the CLAT that is not included in LAN 
segment of CLAT.  Then, the CLAT SHOULD perform a stateless translation 
[RFC6145] so that the IPv4 packets from the CLAT IPv4 host address are 
translated to the CLAT WAN IPv6 address as described in [RFC6145]. ND 
Proxy MAY be used. EUI-64 ID based addresses SHOULD NOT be used.

Please note that RFC 4389 section 4.1.3.3 
http://tools.ietf.org/html/rfc4389#section-4.1.3.3 prohibits a CLAT from 
performing ND Proxy if RA packets are received on the downstream interface.

When both DHCPv6-PD and ND proxy are not available a CLAT MAY use a 
dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address 
to be used in stateless translation [RFC6145].  This will allow the CLAT 
to avoid possible IPv6 address duplication issues between an IPv6 
address for   stateless translation [RFC6145] in the CLAT and an IPv6 
address assigned to native IPv6 nodes behind the CLAT. This document 
describes an example for this case in Example 2. of the Appendix A. The 
IANA assigned EUI-64 ID SHOULD NOT be used for L2 link addressing. 
Network operators SHOULD ensure that the upstream interface of each CLAT 
is connected to an unique upstream IPv6 prefix, to prevent potential 
problems with duplicate IPv6 addressing of downstream interfaces of two 
CLAT's connected in parallel,





I'm relying on you xlat experts to get the preference order right.....
>> The single /64 deployment model may be reality of Release-9 3gpp, but should
>> we be producing a new (xlat) BCP that potentially condones bad practice
>> forever? Especially as future releases of 3gpp seem to be moving away from
>> the single /64 deployment model.
>> e
>
> It does not condone NDproxy forever, i believe the current text is
> clear that DHCP-PD is the preferred path.  Given that that the
> preferred path is only available in vaporware on 3GPP networks and
> this is a BCP, we documented what we know to work in a 3GPP network
> for real .. with real code .. .real customers .... real production
> network.  While, at the same time, saying DHCP-PD is the best path
> when available
I appreciate the intention but I think the text could be improved.
>> I'm worried that we'll create issues for Homenet, because an IPv6 wireless
>> LTE mobile phone acting as a CPE router (with built in CLAT and special
>> processing for single /64 working) is pretty likely to connect into a
>> Homenet in parallel to a domestic wired CPE router (with built in CLAT).
>>
>
> Homenet has a lot of work to do on many fronts, and finding network
> boundaries is one of their most active areas of research
As stated above I now think ND proxy should shut down when a phone using 
ND proxy is connected to Homenet. However, if two wireless devices are 
using CLAT + single /64 + ND Proxy at the moment one phone is tethered, 
wouldn't they both detect RA packets on their downstream interfaces, 
causing both to fail over to a different translation scheme (based on 
fixed IANA address)? This isn't such a crazy scenario: I know of places 
that deliver "fixed" domestic Internet links via wireless; as well as 
some friends who own more than one mobile device per household. Wouldn't 
this cause some interesting oscillation effects, as well as killing 
existing sessions?

>> Can you remove that worry?
>>
>
> I hope i already have.
>
>> Does the WG think Lorenzo's and Hemant's vision of a tethered mobile phone
>> as "just another CPE router" the more correct model?
>
> I have my reservations about the commercial reality of multi-homing
> for residential use, but i think it is viable.
>
> CB
>> regards,
>>
>>
>> Cameron Byrne wrote:
>>> On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant)
>>> <shemant@cisco.com>   wrote:
>>>> I do have to start a new thread to focus this ND Proxy discussion with
>>>> 464xlat.   Elide the use case of a single /64 from the document and then
>>>> the
>>>> following go away too.
>>>>
>>>>
>>>>
>>>> 1.      ND Proxy
>>>>
>>>> 2.      RFC 4389
>>>>
>>>> 3.      Single /64 allocated to the CLAT
>>>>
>>>>
>>> Single /64 is the reality of many of today's access networks, and
>>> specifically important is all deployed 3GPP networks work this way for
>>> IPv6.  Note, there are no known Release 10 networks deployed or any
>>> known support of 3GPP DHCP-PD, AFAIK.  It is known that IPv4 resources
>>> are exhausted in APNIC, and soon to be so in RIPE and then ARIN.  So,
>>> there is no point in waiting for perfect. A single /64 is the only
>>> reality we know in 3GPP, and is therefore the most concrete thing we
>>> have for this BCP, which includes running code / running network.
>>>
>>> http://tools.ietf.org/html/rfc6459#section-5.3
>>>
>>> 5.3.  Prefix Delegation
>>>
>>>      IPv6 prefix delegation is a part of Release-10 and is not covered by
>>>      any earlier releases.  However, the /64 prefix allocated for each
>>>      default bearer (and to the UE) may be shared to the local area
>>>      network by the UE implementing Neighbor Discovery proxy (ND proxy)
>>>      [RFC4389] functionality.
>>>
>>>> During the IPv6 CPE router specification development, for a long time,
>>>> some
>>>> folks from the 3GPPP community asked us to add a use case for a single
>>>> /64
>>>> and ND Proxy to rfc6204.  However, after more careful study, a consensus
>>>> was
>>>> reached to remove the single /64 use case from rfc6204 and rfc6204bis.
>>>> Additionally, I am told the IETF  endorses the  DHCPv6 PD model over a
>>>> single /64.
>>>>
>>>>
>>> I am also told the IETF endorses dual-stack
>>>
>>>> A single /64 cannot be supported on a CPE/CLAT because then the CPE has
>>>> to
>>>> proxy the RA to hosts in the LAN or tethered segment.  There is no
>>>> document
>>>> on a Standards Track in the IETF that defines how to proxy an RA.  I am
>>> Is a standard tack document required?  I assume the point you are
>>> trying to make is that rfc4389 is experimental status.
>>>
>>>> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in
>>>> the
>>>> wireless service provider domain.   If the cellular network does not
>>>> issue
>>>> an RA to the CLAT/UE/CPE, how does the UE know it’s ipv6 default router?
>>>> How is the /64 assigned to the CLAT?
>>>>
>>>>
>>> If you are wondering how 3GPP side works, start here rfc6459
>>>
>>> CB
>>>
>>>> Hemant
>>>>
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
> Ray Hunter <mailto:v6ops@globis.net>
> 25 August 2012 21:27
> The single /64 deployment model conflicts with previous approved IETF 
> BCP. I was also vocal in the discussion on 6204bis.
>
> Specifically: According to BCP 157 RFC6177 "A key principle for 
> address management is that end sites always be able to obtain a 
> reasonable amount of address space for their actual and planned usage, 
> and over time ranges specified in years rather than just months."
>
> The single /64 deployment model may be reality of Release-9 3gpp, but 
> should we be producing a new (xlat) BCP that potentially condones bad 
> practice forever? Especially as future releases of 3gpp seem to be 
> moving away from the single /64 deployment model.
>
> I'm worried that we'll create issues for Homenet, because an IPv6 
> wireless LTE mobile phone acting as a CPE router (with built in CLAT 
> and special processing for single /64 working) is pretty likely to 
> connect into a Homenet in parallel to a domestic wired CPE router 
> (with built in CLAT).
>
> Can you remove that worry?
>
> Does the WG think Lorenzo's and Hemant's vision of a tethered mobile 
> phone as "just another CPE router" the more correct model?
>
> regards,
>
>
> ------------------------------------------------------------------------